Skip to content

feat: Stop using blessed versions list for invariants in the registry#9772

Open
Bownairo wants to merge 1 commit intomasterfrom
eero/blessed-versions-2-5
Open

feat: Stop using blessed versions list for invariants in the registry#9772
Bownairo wants to merge 1 commit intomasterfrom
eero/blessed-versions-2-5

Conversation

@Bownairo
Copy link
Copy Markdown
Contributor

@Bownairo Bownairo commented Apr 8, 2026

ReplicaVersionRecords and the blessed versions list are updated in sync, as we no longer require an extra proposal to have each version "blessed".

This moves the invariants in the registry to use the list of ReplicaVersionRecords, instead of the blessed versions list, as a step towards removing the redundant blessed versions list entirely.

@Bownairo Bownairo force-pushed the eero/blessed-versions-2-5 branch 2 times, most recently from 9a246b6 to 002a1ad Compare April 9, 2026 00:09
@Bownairo Bownairo force-pushed the eero/blessed-versions-2-5 branch from 002a1ad to cc60932 Compare April 9, 2026 04:11
@Bownairo Bownairo changed the title Stop using blessed versions list for invariants in the registry feat: Stop using blessed versions list for invariants in the registry Apr 9, 2026
@github-actions github-actions bot added the feat label Apr 9, 2026
@Bownairo Bownairo marked this pull request as ready for review April 9, 2026 18:53
@Bownairo Bownairo requested review from a team as code owners April 9, 2026 18:53
Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

  1. Update unreleased_changelog.md (if there are behavior changes, even if they are
    non-breaking).

  2. Are there BREAKING changes?

  3. Is a data migration needed?

  4. Security review?

How to Satisfy This Automatic Review

  1. Go to the bottom of the pull request page.

  2. Look for where it says this bot is requesting changes.

  3. Click the three dots to the right.

  4. Select "Dismiss review".

  5. In the text entry box, respond to each of the numbered items in the previous
    section, declare one of the following:

  • Done.

  • $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
    canister behavior changes.", or for item 2, "Existing APIs
    behave as before.".

Brief Guide to "Externally Visible" Changes

"Externally visible behavior change" is very often due to some NEW canister API.

Changes to EXISTING APIs are more likely to be "breaking".

If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.

If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.

Reference(s)

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant